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1. OVERVIEW OF PERSPECTIVE VIEW GENERATOR METHODOLOGY 



In the creation of synthetic environments (virtual reality scenarios), 
two approaches are currently taken: 

(1) Object based simulations 

(2) Database driven simulations 

The first of these is the most commonly encountered, and there are 
numerous examples of such systems. In previous studies by Young, 
Whitney, commercially available software, World Toolkit, was used 
to create an empty universe into which objects may be inserted. In 
this particular example, a flat terrain was generated and tree-like 
objects and buildings were constructed and inserted. Then a tank 
was placed in the scene and was moved around. The tank was 
viewed from a fixed observation point in the scene, and calculations 
were performed to determine the area of the tank viewable from the 
observation point, as it passed behind the various obstructions to the 
line of sight. 

Although this was a simple and rapid way of building such scenes, it 
still has the cartoon-like appearance of object based scenarios, and as 
the complexity of the scene increased in an attempt to achieve more 
realism, the execution speed fell dramatically. It became obvious that 
if true realism is to be achieved, such as a scene with perhaps 
hundreds of differently shaped trees, another method of simulation 
will be required if seamless movement around the scene is to be 
achieved. This means achieving at least 15 image frames per second, 
irrespective of the complexity of the visual scene. 

The database driven simulation provides a possible solution to this 
problem, and is particularly suited to the representation of terrain. 
In such a simulation, the terrain is not regarded as a collection of 
objects, but its physical characteristics are encoded and stored in a 
data base. Consider a flat terrain divided into, say, elements 
measuring 1 meter by 1 meter, and suppose that a color (or gray 
shade) is measured for each square on the terrain. Such data may 
come from aerial photographs, satellite measurements, or from 
measurements taken on the ground. The collection of such 
information, and its correlation with the (x,y) coordinates on the 
ground constitute the database. 
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Now consider the problem of observing the terrain. Suppose we wish 
to generate a view of the terrain and display it in digital form. 
Furthermore, suppose our generated image is to have a resolution of 
256 x 256 screen pixels. Figure 1 shows the possible relationship 
between the grid of screen pixels and the elements on the database, 
for an arbitrary placement of the observation point relative to the 
ground. 





SCREEN VIEW 
OF TERRAIN 



Figure 1 Relationship Between Observation Grid and Terrain 

We define the boresight vector as the vector passing through the 
center of the image, and is specified in terms of the x,y,z coordinates 
of the screen center, and two direction cosines specifying the 
orientation of the vector. If we imagine stepping along this vector in 
one meter steps, we eventually intersect the terrain at some location. 
If we then determine the gray shade of the element at the 
intersection, and places that gray shade in the element corresponding 
to the screen center, we have performed an elementary ray trace 
operation. 

We now introduce the concept of a field of view. If our observation 
of the terrain is made by a camera, its lens would have a certain 
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solid cone of observation determined by the lens. It may have a 
narrow field of view, say 10 degrees, or a wide field of view, perhaps 
as much as 90 degrees. For convenience, let us assume the field of 
view is 20 degrees, a common number for common lenses. We can 
approximate the image plane to a linear distribution of angular 
increments in both azimuth and elevation, as indicated in figure 2. 
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Figure 2 Relationship Between Field of View and Image Plane 

In the figure, we assume that the +-10 degree azimuth field of view 
is distributed over the 256 pixels the image has in the horizontal 
direction. The same argument applies to the vertical direction. What 
this means is that given the direction cosines of the boresight vector, 
the direction cosines of each element in the image may be 
determined. Hence a ray trace may be performed for each pixel, and 
the corresponding gray scale at the point of intersection determined. 
If the collection of gray scale values is displayed, the resulting view 
will be that of a camera with a 20 degree field of view placed and 
oriented in accordance with the boresight vector. It is this approach 
that we define as a perspective view, and the program used to 
compute it is known as the perspective view generator (PVG). 

It is now a simple extension to include the undulating nature of the 
terrain. In such a case, as we move down a particular vector or ray, it 
passes over different ground elements. Knowing the start point of the 
ray, and its direction cosines, for every one meter moved along the 
ray we are able to determine what are the new x,y,z coordinates of 
the current location on the vector, and hence which ground element 
we are over. If the elevation of each ground element is also encoded 
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into the database, we can test to see if the z coordinate of the current 
location on the ray is above the elevation of the corresponding 
ground element. If it is, we have not yet hit the terrain, and a further 
step along the ray may be taken. The ray trace stops when the ray z 
coordinate is equal to the ground elevation, and the corresponding 
gray scale for that element is stored in the image array. The ray 
trace then continues for the next pixel until the whole screen has 
been completed and displayed. Note that, if the terrain is perfectly 
flat, we could use simple geometry to determine ray-ground 
intersections but, with variable elevations, this is not possible, and a 
ray trace is the only method available. 

Clearly, the problem with this method is the computational time 
needed to build the image array. For a view image of 256 x 256 
pixels where the boresight vector is locates 500 m from the terrain, a 
total of 256 x 250 x 500 ray trace steps have to be taken. This means 
that the intersection of a ray with the ground has to be checked 
about 32 million times in construction 1 image frame. In addition to 
this is the time needed to extract, store and display the resulting 
gray shade, although this will only have to be done 256 x 256=65536 
times per frame. To achieve frame rates of 20 frames/sec over half a 
billion ray steps have to be done each second. Although quite 
daunting, it should be remembered that this computation is 
independent of the complexity of the scene, and will remain fairly 
constant whether there is one tree in the view or several thousand. 
In the case of highly complex or cluttered scenes, the ray trace 
method proves more realistic than any object based generator, on the 
same hardware platform. 

So far, we have discussed the boresight vector as being stationary, 
but clearly it may be moved. If it is possible to link the boresight 
vector with a device capable of generation 5 or 6 degrees of freedom, 
such as a joystick or spaceball, then current data from such a device 
may be used to control the boresight vector, hence the image frame. 
In this way, it is possible to fly through a terrain database and 
observe the ground characteristics. Apart from the computational 
time needed to allocate joystick data to the boresight vector, no 
additional time is needed to generate images from a moving observer 
compared to a stationary observer. Functionally, a program which 
generates images from an existing database takes the form shown in 
figure 3. 
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Basically the program is an infinite loop in which position and 
orientation data are obtained from a joystick or other input device, 
direction cosines for each screen pixel are calculated, and a ray trace 
is performed for each ray emanating from each pixel. When the 
ground is hit by the ray, the corresponding gray shade is placed in 
that pixel's location in a frame buffer. When each frame is completed, 
a graphics command displays the whole buffer. 




Figure 3 Generalized Flow Chart for PVG Program 

Most of the work we describe here is based on an existing database 
compiled under contract to the US Army by Nascent, Inc. The 
construction of the database itself is no mean feat, and details of this 
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process may be found elsewhere (Baerl). The original database was 
of Fort Hunter Liggett (FHL) in Central California. Pioneering work in 
this area was originally done by Dr. Wolfgang Baer, and its 
implementation on specialized architecture computers may be found 
in the literature (Baer2). Our intent here is to develop algorithms 
which will execute reasonably fast on commercially available single 
processor workstations. In addition, features regarding target 
delectability in such high resolution databases have been 
incorporated, to demonstrate how existing battlefield simulation tools 
such as JANUS may be integrated with a high resolution database. 
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2. IMPLEMENTATION OF PVG ON SINGLE PROCESSOR WORKSTATION 



The original perspective view generator (PVG) was implemented on a 
multi-processor, transputer based computer. In order to make the 
execution time per frame decrease to a reasonable figure when run 
on a conventional, single processor workstation, several constraints 
were placed on the algorithm. These are 

(1) Only a limited area of terrain is loaded for the PVG. The 
original algorithm had dynamic data loading, which means that only 
part of the database, that being viewed, is maintained in RAM. As the 
viewpoint changes, part of the database is discarded, while other 
sections are loaded. This dynamic database management requires 
some CPU time to execute. In the version reported here, a limited 
terrain area is loaded into RAM, thereby avoiding the 
loading/unloading overhead. The area of terrain which may be held 
in memory depends on the amount of RAM the machine has. The 
development machine, an SGI R4000-based workstation, has 48 
Mbytes of RAM, and may hold an area of about 2km by 2km of data. 
Clearly, this area may be increased by increasing the amount of RAM. 
It was felt that this approach was justified, since we are mainly 
interested in relatively close engagements of ground forces. 

(2) The effect of the movement of the sun with time has been 
ignored. It was felt that this feature, which can require considerable 
computational load and memory resources, does not significantly 
add to the detectability of targets. 

(3) The variation of database resolution with viewing distance 
was not included. The FHL database is available at 1 m, 4 m, 16 m 
and 64 m resolutions, and the transputer based system loaded a 
database pixel into the frame buffer depending on the viewing range. 
Since we are dealing with a limited area of terrain, all of it is 
viewable at the highest resolution, namely 1 m post sizes. 

The best way to explain the operation of the program, and its 
associated algorithms, is to look at each function and describe the 
task it performs. We will start with the main segment 
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PVG_MAIN.C 



This program is the main program segment, and is responsible for 
initializing the database in RAM, and cyclically executing the ray 
trace algorithm. A copy of the include file PVG_DEC.IN is shown, and 
is used to define most of the global constants used in the program. 
The first three variables in PVG_DEC.IN allow the size of the database 
to be set, and the display screen resolution to be set. Note that 
increasing the size of the terrain database beyond that which may be 
contained in RAM will cause the overflow to be swapped to disk. As a 
result program execution will slow down considerably. The layout of 
PVG_MAIN.C is very similar to that shown in figure 3. 

INIT.C 

This program initializes some of the global variables used in the 
program, and loads data from a file cmr.dat which is used in the 
target acquisition algorithms to be discussed later. The program 
begins by requesting the user for a value of MAG, the display 
magnification. A "standard" perspective view window is 256 x 256 
pixels on the screen, which physically turns out to be about 1.5 
inches square. This may be magnified MAG times. A good value for 
MAG is 2, since this produces a View window of about 3 inches 
square, leaving sufficient room on the display for other windows 
created by the program. Only the perspective view window is 
affected by MAG. 

The vector IFOVNOW contains ten elements. The first six are the 
initial position and orientation of the boresight vector, and represent 
a position above the terrain origin (x=y=0), and 700 m above sea 
level, looking down at the terrain. Element IFOVNOW[6] is the field of 
view angle in degrees. The first two elements of the vector RAYSEG 
represent half of the frame buffer in pixels, and they are used in the 
generation of the direction cosines. TAR_X and TAR_Y give the initial 
coordinates of the target. Since the terrain measures 1024 m x 1024 
m, the target starts in the center of the terrain. The final section of 
the program deals with the CMR (cycles per milliradian) data table 
used for the target acquisition function to be described later. 

DATAGEN.C 

The program uses only one of the 4096 m square tiles which form 
the FHL database. This is tile number 33. Since the battlefield 
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measures 1024 x 1024, a window this size may be placed anywhere 
in the tile. The location of the window is defined by the coordinates 
of the lower left comer of the battlefield relative to the lower left 
comer of the tile. The coordinates are expressed in blocks, which 
represent increments of 256 m, hence each tile is divided up into 16 
x 16 blocks. Figure 4 shows how the tile is segmented. Two 1024 m 
square battlefields are drawn in the lower left and upper right of the 
tile. To select these two battlefields, the required coordinates would 
be 0, 0 for the lower left, and 12, 12 for the upper right. 




block 



Figure 4 Division of Tiles into Blocks 

Program DATAGEN requests the user for the coordinates of the lower 
left corner of the battlefield; each must be in the range 0 to 12. 
Another 4 m resolution database is also included with the distributed 
code, also for tile number 33. The user therefore has the option of 
viewing the tile at either 1 m or 4 m resolution. DATGEN then calls 
GET_BLOCK.C. This program loads the data from the appropriate 
database one block at a time, and fills up the array DAT. The array 
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DAT holds the 32-bit numbers corresponding to the 1024 x 1024 
battlefield. The array, therefore is 4 Mbytes in size. For simplicity, 
the code for loading from the 1 m database is separate from the code 
for the 4 m database. Upon exit from DATAGEN, the array DAT has 
been loaded into memory in preparation for the ray trace. 

INIT_ WINDOW 

This program uses GL library calls to initialize three windows. The 
first of these is titled "Fort Hunter Liggett" and is intended to show 
the whole of the FHL database by displaying the 64 m resolution 
database in a window 512 x 448 pixels in size. The next window is 
labeled "Battlefield Area" and displays a fixed, downward looking 
view of the 1024 m x 1024 m area selected in program DATAGEN. 
This window is fixed in size at512x512 pixels. The third window is 
titled "Observer" and displays the view obtained from the ray trace 
program. It is this window which changes as the input device is 
manipulated, and is of a size determined by the user input variable 
MAG. 

BIGMAP 

Program BIGMAP loads the data from the 64 m resolution database, 
and displays it in the window titled "Fort Hunter Liggett." Figure 5 
shows how the FHL database is split into tiles. 




0 1 2 3 4 5 6 



Figure 5 FHL Database Tile Numbering System 
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Program INIT_WINDOW.C to initialize 
the GL graphics window 



/ 

include<stdio . h> 
include " PVG_DEC . IN " 
include<gl/gl .h> 

ong MAPWIN_ID, MAINWIN_ID, BIGMAP_ID; 

init_window( ) 

{ 

extern int MAG; 
pref size ( 512 , 448 ) ; 

BIGMAP_ID=winopen ( "Fort Hunter Liggett"); 
color (BLACK) ; 
clear ( ) ; 

RGBmode ( ) ; 
gconf ig ( ) ; 

prefsize(512, 512); 

MAPWIN_ID=winopen( "Battlefield Area" ) ; 
color (WHITE) ; 
clear ( ) ; 

RGBmode ( ) ; 
gconf ig( ) ; 

pref size (PVG_HEIGHT*MAG, PVG_WIDTH*MAG) ; 
MAINWIN_ID=winopen ( “Observer" ) ; 
color (BLACK) ; 
clear ( ) ; 

RGBmode ( ) ; 
gconf ig( ) ; 



The complete database comprises 56 tiles arranged in an array 8 
tiles wide and 7 tiles high. The shaded tiles have no data available; 
only the clear tiles in the center have terrain data (Figure 5). 
BIGMAP loads the 64 m database in a hierarchical manner. It loads 
by tile, beginning with number 00 and finishing with number 76. To 
do this it utilizes program GET_TILE_64. Program GET_BLOCK_64 
extracts from the database file pvdb.64 a block of 16 x 16 posts. 
When these two called functions are completed, the 64 m database is 
held in an array called FHL. Program BIGMAP then puts this two 
dimensional array into a vector VIEWMAP, which the GL command 
LRECTWRITE is able to display directly into the window labeled "Fort 
Hunter Liggett." The result of this is shown in figure 6 




Figure 6 FHL 64m Database 



CALL_MAP 

This program is similar to BIGMAP, except that it displays the 1024 
m x 1024 m battlefield. It accomplishes this, by selecting every other 
pixel from the data array DAT, which was initialized in DATAGEN. It 
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then writes the resulting array to a linear vector VIEWMAP and 
again uses the GL command LRECTWRITE to place the contents of 
VIEWMAP in the "Battlefield Area" window. Figure 7 shows an 
example of this, as the lower left battlefield in figure 4 selected from 
tile 33. 




Figure 7 Battlefield Area Window 



This completes the initialization part of the program, which now 
enters an indefinite loop. The following programs are called each 
time through the loop 

TARGET 

In order to evaluate the performance of target acquisition algorithms 
when used with a high resolution database, some type of target has 
to be inserted into the terrain. This presents a fundamental difficulty 
in a ray trace type of program, since objects are not defined, but 



14 








instead are perceived by the viewer as an expected collection of gray 
shades. For example, a tree is a collection of darker 1 m x 1 m 
elements set against a background of lighter shaded grass. As a 
result, it is difficult to insert artificial objects, such as targets, onto 
the terrain. The problem is solved by modifying the database in the 
locality of the target, to include its size. For example, the target is 
considered to be a regular prism (block) measuring 4 m x 6 m, and 
standing 4 m high. The variables TAR_X and TAR_Y define the 
location of the target's left nearside corner on the database. The 
array DAT is modified to 

(1) Increase the terrain elevation within the 6x4 footprint by 

4 m. 

(2) Change the nature bit to indicate a man-made element. 

(3) Alter the color of the element to that of the target. In the 
case of the distributed software, the target is colored red for ease of 
recognition. Actually, TARGET performs other functions as well as 
embedding the target into the database. These other functions 
include 

(1) Providing the target with some motion. In the program, the 
(x,y) coordinates are increased 1 m for each frame. This is an 
arbitrary motion intended simply to make a moving target viewable 
by the observer. The target could, for example, be controlled by 
another operator using a mouse. The programmed motion causes the 
target to move diagonally across the battlefield from its initial 
position in the center. 

(2) Small squares are written to the Battlefield Area map to 
indicate the current locations of the target and the observer. This is 
to assist the operator close in on the target if it is not viewable from 
the Observer window. The target is colored red, while the observer is 
green. 

SPACEBALL 

The spaceball is the input device of preference, although the 
distribution software has a mouse version. Both devices are 
supported through GL function calls to control the position and 
orientation of the viewpoint from which the ray trace algorithm is 
performed. Essentially, this program reads inputs from the device 
and loads the first six elements of the IFOVNOW vector. The use of 
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the spaceball is intuitive, but the MOUSE program source code 
defines how to control the viewpoint with the mouse and its buttons. 

GENDDCOS 

This program is identical to that used in the Sun version written by 
Wolfgang Baer. The purpose of this routine is to calculate the 
elements of the 2 dimensional array DDCOS[3][3]. These elements are 
defined as 

DDCOS[0][i]= direction cosines of start ray, i.e. the ray through 
lower left screen pixel. 

DDCOS[l][i]= change in direction cosines when a row index 
changes. 

DDCOS[2][i]= change in direction cosines when a column index 
changes 

With this array, it is possible to calculate the direction cosines of a 
vector from any screen pixel, which is what is needed in the ray 
trace algorithm. In order to handle the coordinate transformations 
used in this program, two other functions are used, 
VEH2UTM_MATRIX.C and MATNMUL.C. These programs are also 
identical to those used in the original Sun version. 

ZIGZAG 

Program ZIGZAG is the heart of the PVG system and performs the ray 
trace operation above the current terrain, for all 256 x 256 screen 
pixels. Its main inputs are 

(1) Array DAT containing the battlefield terrain data. 

(2) Vector IFOVNOW defining where the observer is 
located relative to the terrain. 

(3) Array DDCOS containing how the direction cosines 
vary for incremental row/ column screen pixels. 

Figure 8 shows how the screen coordinates are defined for each pixel. 
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Figure 8 Definition of Pixel Screen Coordinates 

The ray trace starts with the lower left pixel (0,0). It is important to 
recognize that the direction cosines are also the changes in the (x,y,z) 
coordinates of the start point of the ray trace, for each unit step 
along the ray. Hence, knowing the direction cosines (DC's) for the first 
pixel, each meter step along the ray, allows us to determine the 
(x,y,z) coordinates of that point on the ray. The (x,y) coordinates 
allow us to determine which element of DAT we are currently above, 
while the z value may be compared with the elevation of the 
elements whose (x,y) coordinates we have just found. By comparing 
these elevations, we can determine whether a ground intersection 
has occurred. If not, we take another step along the ray and test 
again. This continues until either we do hit the ground, or the (x,y) 
coordinates pass outside the battlefield limits. 

If we hit the ground, one of several cases is considered. First, we 
determine if the target has been hit, by examining the nature/man- 
made bit of the element of DAT. If this is the case, the color red is 
written into the corresponding screen pixel; if not, function HITGRND 
is called to determine what color should be given to the pixel. If we 
pass outside the terrain database before hitting the ground, the pixel 
is given the color white. This enables us to perceive the "edge" of the 
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battlefield. The color/gray shade of the pixel is written into the 
vector VIEW, and it is this vector which will be displayed later. 

Once the first screen pixel has been dealt with, pixel (0,1) is treated 
in the same manner, and so on until the first column has been 
considered. Then element (1,0) is ray traced, then (1,1) until the 
second column is completed. This raster proceeds until the right- 
most column completes the whole screen. Program ZIGZAG, therefore, 
consists essentially of a double loop in which the column index is 
incremented, then the row index, and, for each iteration 
corresponding to a particular pixel, a ray trace is performed. 

Investigation of the time that the whole PVG program takes to 
execute (code profiling) indicates that about 70% to 80% of that time 
is spent in the ray trace algorithm. Improving the frame rate of the 
program, therefore, means optimizing the ray trace operation as 
much as possible. One of Dr. Baer's more significant contributions is 
the so-called zig-zag argument which is applied to the ray trace 
when successive pixels in the same column are considered. Figure 9 
shows two ray traces for successive column pixels, intersecting the 
ground. 




Figure 9 Zigzag Feature of Ray Trace 



Suppose the first ray intersects the ground at A, after making 1000 
steps along the vector. When the column pixel is incremented for the 
next ray trace, we do not start the ray trace from the observer, 
perhaps making 1003 steps along the vector before intersecting the 
ground at B. Instead, be begin our stepping 1000 steps along the new 
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vector from C, thereby reducing considerably the time taken to 
intersect the ground. 

A final section of ZIGZAG calculates the total number of pixels 
correspond to ray hits on the target. This number, which is a 
dynamic measure of visible target area, is used later in the target 
detection algorithm. 

HITGRND 

This program determines what color should be stored in the 
appropriate screen pixel if the ray trace has not hit the target. Note 
that a ground hit will be reported if the ray trace intersects the 
terrain. Considering the way the terrain is defined, such a hit may 
occur if the ray hits the top of a tree, as shown in figure 10 by line 
XY 

The current program allows three possible options. 

(1) Bald Terrain: In this option, the under cover index confirms 
that an overhang does not exist above the element where the ground 
hit took place. In this case the gray shade stored in the screen pixel 
is extracted from the appropriate bit field in the database element. 
This is indicated by line AB or by line XY in figure 10 

(2) Ground hit Below Overhang: Here, the undercover index 
confirms an overhang does exist at the ground hit element. In figure 
11, a ground hit by ray EF would be such an example. In this case, it 
is assumed that the ground element is in a shadow, and the color 
black is stored in the pixel. 

(3) No Ground hit, but Overhang: This is typified by the ray 
beginning at G in figure 10. Here the color of the pixel is again 
extracted directly from the corresponding ground element. 

(4) Ray Passes Beneath Overhang: In this case, we are beneath 
the overhang, but have not yet hit the ground. In program HITGRND, 
this option is still under development. What we want to do is 
basically to continue the ray trace beneath the overhang until one of 
two things happens: 

(a) The ground is hit, in which case the color black 
(shadow) is displayed, or 
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(b) The ray leaves the overhang without hitting the 
ground, as does ray CD in figure 10. In this case, if a return to 
ZIGZAG is made, having suitably updated our position on the ray, a 
normal ray trace can continue in ZIGZAG. This case will occur only 
when the observer is close to the ground, but could be significant if 
the PVG program is used for ground-to-ground encounters. 




Figure 10 Ray Interactions with a Tree 



ACQUIRE 

This program implements the target detection and recognition 
algorithms used in the CASTFOREM approach, and applies them to the 
target and high resolution database found in the PVG program. The 
algorithms may be specified by the flow chart in figure 11. In 
implementing these algorithms, many improvements over their usual 
implementation in wargaming simulations such as JANUS may be 
made. This is because many of the parameters used in the algorithms 
become dynamic, and change from frame to frame. This is in contrast 
with the JANUS approach where, for example, the percentage of a 
target partially obscured by an object is fixed in the whole 
simulation, even though the target moves on the terrain. In the PVG 
program, targets may sometimes hide behind trees, or may move out 
into open ground. Their detectability will therefore vary as the target 
moves. 



20 




Figure U CASTFOREM Target Detection Algorithm 




The program begins by calculating the range to the target from the 
observer. Then the apparent contrast is calculated. Based on the 
apparent contrast, the number of cycles/milliradian may be 
determined from the lookup table loaded into array CMR. Given the 
area of the target in the current frame, the number of cycles 
resolvable on the target may be determined. Then P-infinity, the 
probability of detecting, recognizing and identifying the target, may 
be found. 

Finally, the time for acquisition is determined, based on the 
calculated P-infinity values and on a random draw to represent the 
probability that the target will be seen in a single field of view scan. 
Acquisition will occur if this time is less than the field of view scan 
time, which is defined to be 10 seconds. The completed results, 
including the three P infinity values and the results of the target 
acquisition tests (1 or 0) are written to the text screen for each PVG 
frame. 

DISPLAY 

Display writes the vector VIEW to the "Observer" window, and 
consists of two commands. The first is a RECTZOOM command which 
increases the size of the pixel array by the variable MAG. This will 
match the pixel array to the size of the screen in INIT_ WINDOW. The 
second instruction is the LRECTWRITE command. This takes a vector, 
VIEW in this case, and writes it to the currently active window. This 
is a powerful GL command which handles a graphical array write 
operation to the screen with a single command. 

RESTORE 

This program is the last in the loop, and its function is to remove the 
target from the database. Recall in program TARGET how the terrain 
database, stored in array DAT, was modified to include a prismatic 
target, colored red, at the current target location. Program RESTORE 
restores the database to its original condition so that in the next 
frame TARGET may re-insert the target at the new target position. 
The restoration process consists of reducing the elevation in the 
vicinity of the target, and restoring the nature bit. 
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This concludes a description of the major functions in the PVG 
program. Figure 12 shows a sample frame produced by the program. 




Figure 12 Sample Frame Produced by the PVG Program 



Clearly there are many functions in the complete program, and 
therefore many dependencies between different sections of the 
program. A copy of the MAKEFILE for compiling the code follows, 
showing how each run time module is constructed. 

When the complete program runs, all three graphics windows, and a 
text window are shown on the screen. This is illustrated in figure 13. 
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dumpster 



103/0 P/A( recog) 
100/1 ?/A(rscog) 
103/1 P/A( recog) 
100/1. P/A(recog) 
103/1 P/ AC recog) 
1B0/1 P/A( recog} 
100/1 P/ A (recog) 
100/1 P/A(rr?cng) 
100/1 P/A( recog) 
100/1 P/A( retag) 
100/1 P/A( recog) 
103/1 P/A( recog) 
103/1 P/ A( recog) 
103/1 P/A(reccig) 
100/1 P/A(recog) 
103/1 P/AC recog) 
103/1 P/ACrecog) 
100/1 P/A(recog) 
103/1 FV'A(recog) 
100/1 P/ACrecog) 
103/1 P/ACrecog) 
100/1 P/A( recog) 
100/1 P/A(rscog) 



93/0 ?/ A( i dent) 
99/ t P/ AO dent) 
99/1 P/A(ident) 
99/1 P/ AO dent) 
93/1 P/ACidsnt) 
99/1 P/A<1dent) 
99/1 P/A(1dent) 
99/1 P/A(ident) 
93/1 P/AC ident) 
99/1 P/A(1dent) 
99/1 P/ A(i dent) 
99/1 P/AO dent) 
93/1 P/AC i dent) 
99/1 P/AO dent) 
99/1 P/AO dent) 
99/1 P/AO dent) 

93/1 P/ AO dent) 
99/1 P/AO dent) 
99/1 P/AO dent) 
99/1 P/A(1dent) 
99/1 P/AC 1 dent) 
99/1 P/AO dent) 
99/1 P/AO dent) 



P/Avdetect)* 
P/A(detect)- 
P/A(detect)= 
P/A(detect)= 
P/A(detect)- 
P/A(detect)- 
P/A(detect)= 
P/A(detect)- 
P/A(detect)« 
P/A(detect)- 
P/A(detec*)- 
P/A(detect)- 
P/A(detect)“ 
P/A(detect)=i 
P/A(detect)“ 
P/A« detect)- 
P/A(detect)- 
P/A(detect)= 
PZA(detect)- 
P/A(detect)~ 
P/A(detect)= 
P/A(rietfect)- 
P/A(detect)= 



snapshot 



& 

systemtour 



cdrom 



Figure 13 Screen Layout for PVG Program 
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3. MENUING SYSTEM FOR DATA INPUT 



The system described so far demonstrates the feasibility of 
implementing a perspective view generator on a single processor 
workstation. Another important aspect of using such a program is the 
flexibility with which targets, their motion, and the environment in 
which they operate may be programmed. This would allow the user 
to program several engagements over different terrain types, with 
different targets and environmental scenarios. This would be 
accomplished with a menu system which would initialize the 
program. Although not implemented in the distribution version of 
the software, all the elements needed to do so have been explored. 
Full implementation will have to be deferred until later, due to time 
constraints for this fiscal year. The menu system establishes three 
data sets, dealing with 

(1) Display setup 

(2) Scenario Parameters 

( 3 ) Target Characteristics 

The following text shows the interaction between the menuing 
system and the operator to initialize the program in the three areas 
outlined above. 



DISPLAY SETUP 



1 - Select one 4 x 4-km tile from the grid by placing the cursor on it 
and clicking the mouse button. 

Is this the area you want? Y 

Choose one: Y = Yes 
N = No 



2 - From this tile, select the lower left comer of a 1 x 1-km area by 
clicking on the mouse button. 

Is this the area you want? Y 
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Choose one: Y = Yes 
N = No 



3 - Select a size for the graphics display M 

Choose one: S = Small 

M = Medium 
L = Large 



4 - Is this the size you want? 

Choose one: Y = Yes 
N = No 



,Y 



5 - Would you like to edit the input file? Y 

Choose one: Y = Yes 
N = No 

If Yes, would you like to generate a new input file from 

the default file? Y 

Choose one: Y = Yes 
N = No 

If No, enter name of existing file to edit 



SCENARIO PARAMETERS 



Review the following input file. 

Change ONLY the parameter values. 

Make NO other changes to file. 

When finished editing select Save As from File menu, enter name of 
file, and Quit. 
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TARGET CHARACTERISTICS 



1 - Target Type C 

Enter one target type: 

A = M106A1 (Trailer) 

B = M125A1 (10 Ton Truck) 

C = M1A1 (Abrams Main Battle Tank) 

D = T-62 (Main Battle Tank) 

E = M101 105mm (Howitzer) 

F = M109 155mm (Self-Propelled Howitzer) 

G = M2 (Bradley Armored Personnel Carrier) 



2 - Number of Targets 
Enter 1-12 



1 



3 - Target Configuration .... 

Choose one: G = Group 
C = Convoy 



G 



4 - Target Motion 

Choose one: S = Stationary 
M = Moving 



S 



ENVIRONMENTAL CHARACTERISTICS 

5 - Value for Atmospheric Transmittance 0.5 

Specify transmission of radiation through atmosphere 
in sensor’s spectral bandwidth: 
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Value between 0.0 - 1.0; 
1.0 = Best Transmission 



6 - Amount of Cloud Cover 1/8 

Value must be in eighths, from 0 - 8/8; 

0 = No Clouds; 8/8 = Total Cloud Cover 



7 - Amount of Clutter 1 

Based on your selected 1 x 1-km area, indicate density of 
bushes and trees in the area: 

0 = Low Level of Clutter 

1 = Medium Level of Clutter 

2 = High Level of Clutter 



SENSOR CHARACTERISTICS 

8 - Sensor Type D 

Choose one: D = Direct Vision 
T = TV 

If TV is selected then choose an option from below: W 

Choose one: W = Wide Field of View 
N = Narrow Field of View 



OBSERVER CHARACTERISTICS 

9 - Type of Observer G 

Choose one: G = Ground-Based 
F = Flyer 
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10 - Workload 



L 



Complexity of controls and displays necessary to operate 
equipment and difficulty and complexity of maintaining it: 

Choose one: L = Low 

M = Moderate 
H = High 



When finished editing select Save As from File menu, enter name of 
file, and Quit. 



TARGET CHARACTERISTICS 

TYPE FUNCTION HEIGHT (m) WIDTH (m) SPEED (km/hr) 

M106A1 . . .Trailer 2.03 2.36 30.00 

M125A1 . . 10 Ton Truck . .3.28 2.89 30.00 

M1A1 Abrams 2.89 3.65 40.00 

T-62 . . . Battle Tank 2.39 3.30 29.00 

M109A2. . Self-Prop Hwtz . 3.28 3.15 35.00 

M101 105mm. .Hwtz . . 2.16 1.52 00.00 

M2 Bradley (APC) . . 2.97 3.20 40.00 

Range of allowable speeds for OH-58D Kiowa Warrior: 

204 km/h - economy cruising 2 19 km/hr - max cruising 
241 km/hr - max 

Speed for ground-based observer: 

0 - min 40 km/hr - avg 60 km/hr - max 
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4. ENHANCED TARGET ACQUISITION ALGORITHMS 



One objective of this year’s project has been to continue the 
development of enhanced target acquisition software, for use in both 
the Perspective View Generator and JANUS (A). New algorithms will 
build on outputs from the ACQUIRE program described in Section 2. 
Data needed for new computations is provided by the user via the 
menu system described in Section 3. 

The 1995 PVG target acquisition implementation first determines 
that there is clear line of sight between the target and observer. If 
this criterion is met, the system calculates observer-to-target range, 
inherent target-to-background contrast, and apparent contrast after 
degradation due to atmospheric attenuation. These are the primary 
factors used by the ACQUIRE program to determine threshold values 
for three target acquisition probabilities, that is, whether it is 
humanly possible for the target to be detected, recognized, and 
positively identified. 

If ACQUIRE determines that the target can be acquired, the three 
calculated P-infinity values next are modified based on the user- 
entered menu selections. These selections may cause the 
probabilities to be either increased or decreased due to factors 
specific to the combat mission being simulated. The resulting 
modified P-infinity values then are used to calculate a modified time 
for acquisition, which is compared with the field of view scan time to 
determine whether the target will be detected, recognized, and 
identified in the time available. The result is a yes-no output similar 
to that from ACQUIRE but now taking into account additional human 
factors that influence target acquisition. 

The 1995 development effort has been based on preliminary work 
done in 1993 and 1994 under a related project, Improved Target 
Acquisition Algorithms for Janus (A). This project was conducted to 
evaluate the various factors that affect human target acquisition 
performance and that might be considered for inclusion in combat 
models; details may be found elsewhere (Lind). Some 150 factors 
were identified, falling into six categories: mission/tactics, target, 
environment, target area, sensor, and observer. This very large list 
was reduced to 37 factors that show reasonable potential for 
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implementation; 11 of the resulting short list were selected for 
initial modeling in 1995 (see table l). 1 



Table 1 Factors Selected for Initial Modeling 



Acquisition 

Parameters 


Data 

Type 


Units 


Range 

of 

Values 


Quantity 
of Values 


Affects Tasks: 


Target type 


Alpha 


None 


A- G 


7 


Detection 

Recognition 

Identification 


Number of 
targets 


Integer 


None 


1 - 12 


12 


Detection 


Target 

configuration 


Alpha 


None 


G or C 


2 


Detection 

Recognition 

Identification 


Target motion 


Alpha 


None 


S or M 


2 


Detection 


Atmospheric 

transmittance 


Real 


km' 1 


o 

r—H 

1 

o 

o 


N/A 


Detection 


Amount of 
cloud cover 


Integer 


None 


0-8 


9 


Detection 

Recognition 

Identification 


Amount of 
clutter 


Integer 


None 


0-2 


3 


Detection 

Recognition 

Identification 


Sensor type 


Alpha 


None 


DorT 


2 


Detection 

Recognition 

Identification 


Sensor field of 
view 


Alpha 


None 


WorN 


2 


Detection 

Recognition 

Identification 


Ground or air 
observer 


Alpha 


None 


G or F 


2 


Detection 

Recognition 

Identification 


Workload 


Alpha 


None 


L, M, H 


3 


Detection 

Recognition 

Identification 



appreciation is expressed to Jennifer Swoboda, Army Research 
Laboratory, Aberdeen Proving Ground, who carried out most of the 
1995 analyses related to the 11 factors and developed the menu 
system. 
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TARGET TYPE 



Seven types of targets have been defined for this initial effort (see 
the menus of Section 3). The user selects one of the listed target 
options for a given run. This automatically provides the program 
with target height, width, and speed to be used in calculations for 
this run, so that separate entry of these values is not required. 

NUMBER OF TARGETS 

Detection performance improves as the number of targets in view 
increases. Significant differences have been measured for one, three, 
and nine vehicles. Thus, although the user enters the quantity of 
targets he wishes to engage for a given run (up to 12), only three 
categories actually will be used in calculations: 1 target, 2 to 5 
targets, and 6 to 12 targets. Figure 14 shows the quantitative 
relationship between the number of targets and detection 
performance. 

TARGET CONFIGURATION 

Detection performance is substantially affected by the spatial 
formation of multiple targets, especially when the targets number 
more than three. Figure 14 shows the relationship between target 
configurations (groups and convoys) and detection performance. 

TARGET MOTION 

Whether a target is stationary or moving affects detection, since 
moving objects catch the attention (even if seen peripherally). 
However, recognition and identification performance deteriorate if 
objects move at very high rates that will blur their features. If 
mobile, it is assumed that the target is moving at the fixed rate 
included in the program’s target table for the selected type of target. 
This rate will improve detection performance but will not degrade 
the ability to recognize and identify the target. 

ATMOSPHERIC TRANSMITTANCE 

Atmospheric transmittance is needed for the ACQUIRE program’s 
calculations. Transmission of radiation in the sensor’s spectral 
bandwidth through the atmosphere is used in determining contrast 
attenuation as a function of the range to the target. 
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Figure 14 Performance Versus the Number of Targets 
AMOUNT OF CLOUD COVER 

Cloud shadows on the ground can affect acquisition much as clutter 
does, changing the apparent shape of a target and possibly causing it 
to blend into the background. Clouds covering between 3/8 and 7/8 
of the sky will have the greatest dappling effect; a cloudless sky or 
one completely overcast will not substantially influence acquisition. 
The PVG does not model the sky, so it is necessary for the user to 
enter a value for this parameter. 

AMOUNT OF CLUTTER 

The density of target area clutter, proximity of clutter to the target, 
and how similar in appearance the clutter objects are to the target all 
strongly influence target acquisition performance. Theoretically the 
PVG should be able to measure the instantaneous clutter level 
around the target as the target moves across the terrain, but this is 
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currently beyond the capability of the system. Instead, the user will 
select a clutter level for use in probability calculations. 

SENSOR TYPE 

The type of sensor determines which lookup table of cycles per 
milliradian versus apparent contrast will be used for ACQUIRE 
calculations. At present only one table is included in the PVG (the 
CMR array, for direct vision acquisition), but inclusion of other tables 
will not be difficult. The menu system presently provides options for 
additional tables: one for direct vision and at least one for use when 
a television-type electro-optical sensor is utilized for acquisition. 

SENSOR FIELD OF VIEW 

Different lookup tables of cycles per milliradian versus contrast (CMR 
arrays) must be used for a sensor’s various fields of view, for those 
sensors that provide the capability to switch between view fields. As 
noted above, at present only one CMR array is included in the PVG, 
but additional arrays can be added easily. 

GROUND OR AIR OBSERVER 

The PVG user can take the part of a hunter-observer using the 
spaceball to move across or over the terrain searching for the target. 
A ground observer will rotate the spaceball to change direction and 
move it forward and back to change speed. An air observer will 
have these same capabilities, but also can pull the spaceball upwards 
to change altitude. Selection of the Ground-based or Flyer option on 
the menu will determine spaceball use. 

WORKLOAD 

High observer workloads decrease attention levels and increase 
mental stress, physical stress, and fatigue se reducing the probability 
that the target will be detected and, if detected, will be correctly 
identified. Workload level must be specified by the user based on 
the modeled situation, including the difficulty of operating weapons, 
sensor systems, and other equipment. 



33 



5. RESULTS AND FUTURE WORK 



1. Simple perspective view generator code has been developed 
for a single processor SGI workstation. This provides a small program 
(about 400 code lines) for prototyping additional capabilities, such as 
NVESD detection algorithms. 

2. The PVG works with a limited data base, about 3 km 
square, so that dynamic data flow management is avoided. 

3. The program uses only single resolution data, usually the 
highest resolution available at 1 m x 1 m., although other resolutions 
work also. 

4. Use of a spaceball is recommended for observers which fly, 
although a mouse based version is also available. Ground based 
observers are also supported. 

5. The size of the terrain rendered depends only on the local 
RAM of the machine. A machine with 48 Mbytes displays about 10 
sq km. 

6. The frame rate on an entry level SGI Indigo (R4000 
processor) is about 1.5 frames/second, if two auxiliary graphics 
screens are displayed. 

7. Program may be adapted to any machine supporting 
OpenGL graphics language. 



As far as future work is concerned, several avenues could increase 
the utility of the work completed so far. 

1. The menuing system outlined previously should be 
implemented to provide a flexible tool for modeling a wide variety of 
engagements. 

2. The ACQUIRE program should be enhanced to include the 
additional algorithms that have been developed to improve the 
modeling of target acquisition performance, for better agreement 
with observed field test results. 
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3. Parallel architectures for dividing the computing time for 
the ray trace algorithm should be investigated. Such architectures 
may be at the PC or workstation level, and preliminary work on the 
latter indicates that frame rates in the order of 10 are achievable 
with machines currently at NPS. 

4. The representation of target in the database terrain has to 
be improved. The use of z-buffering on the SGI workstations should 
allow realistic target superpositioning. If possible, such targets 
should be rendered using commercial drawing aids, such as Autocad. 

5. A small scale JANUS type program could be developed in 
which two players control small forces independently of each other. 
Such a demonstration would indicate that a high resolution database 
may lead to different strategies for the same scenario played on a 
conventional JANUS terrain. 

6. Implementation of the software on a multi-processor 
workstation, say with 8 CPUs, and 256 Mbyte or more memory 
would allow video frame rates adequate for a complete tile of 
terrain. This would allow realistic, multi-unit engagements to be 
simulated, using multiple players. 
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